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ABSTRACT 



A method and system for establishing a shared secret 
between a plurality of devices using an authentication token. 
An authentication token is used to establish a shared secret 
between a local device and a remote device to provide user 
authentication, data encryption, and integrity protection. The 
authentication token may be used in a variety of ways to 
authenticate a user. First, a time-synchronized authentication 
token can generate a first character string that is communi- 
cated to a workstation. The workstation can manipulate the 
first character string to generate a second character string 
and send the second character string to a server. The server 
then compares the second character suing with a plurality of 
possible matching character string values and determines the 
first character string. In another implementation, a challenge 
from a server can be received and processed by a challenge - 
response authentication token to generate a character string. 
The generated character string is then communicated to the 
workstation to establish a shared secret. A smart card may 
also be used to establish a shared secret between a local 
device and a remote device using similar techniques. 

73 Claims, 15 Drawing Sheets 
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METHODS AND SYSTEMS FOR 
ESTABLISHING A SHARED SECRET USING 
AN AUTHENTICATION TOKEN , 

FIELD OF THE INVENTION 

The present invention relates generally to secure 
communications, and more particularly, to methods and 
systems for establishing a shared secret between devices 
connected over a communication medium using an authen- 
tication token to provide user authentication, data 
encryption, and integrity protection, 

RELATED ART 

Traditionally, network users simply enter a user name and 
a password to gain access to network resources and other 
users of the network. After entering a user name and 
password to gain access to the network, a user usually sends 
and receives data in the clear during the network session 
without any protective measures. That is, the data is sent 
over a communication channel "as-is" without any level of 
security protection. This traditional method of gaining 
access to and communicating over a network presents many 
problems with regard to the integrity of the network. 

First, a user name and password only provides a minimal 
level of user authentication to access the network. If the 
password is simple (e.g., the user's birth date) a hacker can 
easily determine the user's password and access the network 
with this information assuming the user's name. Second, 
sending and receiving data in the clear makes the network 
susceptible to eavesdroppers. An eavesdropper can intercept 
data sent over a network communication channel and use it 
for improper purposes such as hijacking the user's session. 
Moreover, data sent in the clear is susceptible to malicious 
software that can modify the data (e.g., delete or change bits) 
or copy the data to a hidden peripheral (e.g., copy data to a 
remote storage device unknown to the user). 

Many users currently rely on authentication tokens to 
provide an additional level of user authentication based on 
"something you have" (versus "something you know", like 
a password). Authentication tokens are physical devices that 
people carry while passwords are simply remembered. 
There are a variety of authentication tokens currently avail- 
able in the marketplace. These authentication tokens include 
time-synchronized authentication tokens, challenge- 
response authentication tokens, and smart cards. 

A time-synchronized authentication token typically dis- 
plays a different character string (i.e., password) at 
approximate, predetermined intervals of time (e.g., every 
minute). In this instance, for example, a server and token 
synchronize (within a predetermined tolerance) using the 
time of day in minutes to produce a character string (e.g., the 
time of day in minutes encrypted with a secret code known 
only to the token and the server). A user then enters the 
current character string displayed on the token into a work- 
station to authenticate the user to a server. The workstation 
sends the character string to the server in the clear. The 
server checks the character string against a list and then 
determines whether the character string could have been 
generated by the token in the last few minutes (to allow for 
delay in typing and transmission). 

A challenge -response token is a device with a keypad, 
such as a card. Traditionally, when authenticating using this 
token, for example, the user first contacts a server which 
generates a challenge (e.g., a character string) and sends it 
to the user via a local computer. The user then enters the 
challenge into the token which processes the challenge and 
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displays a response (e.g., another character string). The user 
sends the response to the server which checks the response 
against a predetermined character string value. If there is a 
match, the server grants the requested access. 

5 A smart card is a device with a central processing unit 
(CPU) and memory. When inserted or positioned near a 
smart card reader, the card communicates with the reader to 
transfer data or perform desired functions. The smart card 
may have any shape. For instance, the smart card may have 

10 the shape of a credit card or a pendant worn on an article of 
clothing. 

Any of the aforementioned authentication tokens may 
require an authentication code for operation. The activation 
code may be in the form of a personal identification number 

15 (PIN) or a bio me trie. For example, to operate a time- 
synchronized authentication token, a user may be required to 
enter in a character string or touch an area of the token with 
their thumb. With a challenge response token, an activation 
code may be required to activate the token before entering 

20 the challenge. Finally, certain smart cards may require a user 
to enter an activation code to "unlock" information stored 
therein (e.g., character string). Usually, after some number 
of wrong guesses, the card "locks" itself and will not permit 
access to stored information. If the information is accessible, 

25 the smart card reader can communicate it to a workstation to 
use for authentication purposes. 

Typically, with time -synchronized authentication tokens, 
challenge-response authentication tokens, and smart cards, 

30 the character string values generated therein are transferred 
between a user's workstation and a remote computer in the 
clear. As a result, all communications between the user and 
the remote terminal become susceptible to hijackers and 
eavesdroppers who can easily decipher the unprotected code 

35 and intercept communicated information. 

In conventional use, the only purpose for authentication 
tokens is user authentication. No session key — a quantity 
used to encrypt or decrypt information during a session — is 
established and therefore no integrity protection or confi- 

40 dentiality is provided for the session. In addition, there is no 
way for the client to know that it is talking to the correct 
server. The character string value generated by an authen- 
tication token usually contains less than 32 bits of significant 
information. This allows for an inexpensive display and 

45 avoids requiring users to enter long character strings. 
However, it makes the system more vulnerable to various 
attacks. 

Shared secret key exchange protocols allow two comput- 
ers with a shared secret to establish a stronger shared secret 

50 without risking attacks on the shared secret. The stronger 
shared secret may then be used to encrypt data exchanged 
between them. These protocols are commercially available 
and include the Bellovin-Merritt shared secret key exchange 
protocol and the Strong Password only Authentication Key 

55 Exchange (SPEKE). A description of several shared secret 
key exchange protocols is included in Kaufman, Perlman, 
and Speciner, Network Security: Private Communication in 
a Public World, Prentice Hall PTR (1995) (hereinafter 
"Network Security"). The Bellovin-Merritt protocol is dis- 

60 cussed in Network Security, pp. 249-253 and described in 
U.S. Pat. No. 5,241,599. A discussion of SPEKE can be 
found in D. Jablon, "Strong Password only Authentication 
Key Exchange," Computer Communication Review, ACM 
SIGCOMM, vol. 26, no. 5, pp. 5-26, October 1996. Shared 

65 secret key exchange protocols strengthen password-based 
systems by avoiding sending the password in the clear. 
Currently, shared secret key exchange protocols are not used 
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with authentication tokens to enhance session security. FIG. 5b illustrates a method for establishing a shared 

Therefore, there is a need for a solution that involves both secret using a time-synchronized authentication token and a 

authentication tokens and shared secret key exchange pro- shared secret key exchange protocol consistent with an 

tocols to provide adequate user authentication, data alternative implementation of the present invention; 

encryption, and integrity protection. 5 FIG> 5c illustrates a method for establishing a shared 

secret using a time-synchronized authentication token and a 
shared secret key exchange protocol consistent with yet 

Based on the foregoing shortcomings, it is desirable to another alternative implementation of the present invention; 

establish a shared secret between parties communicating FIG. 6 illustrates a method for establishing a shared secret 

over a network using an authentication token to provide 10 using a challenge-response authentication token consistent 

adequate user authentication, data encryption, and integrity with the present invention; 

protection. FIG. 7 illustrates a method for establishing a shared secret 

Methods and systems consistent with the present inven- using a challenge -response authentication token and a PIN 

tion meet the foregoing desires. Specifically, a method for 15 consistent with the present invention; 

establishing a shared secret among a plurality of devices, FIG. 8 illustrates a method for establishing a shared secret 

comprises the steps of providing an authentication token; us ing a challenge-response authentication token and shared 

and utilizing the authentication token to establish a shared secret key exchange protocol consistent with the present 

secret among the plurality of devices. invention; 

A system for establishing a shared secret among a plu- 2 o FIG. 9a illustrates a method for establishing a shared 

rality of devices comprises an authentication token; a local secret between a local device and a remote device using a 

device; and a remote device, wherein the authentication smart card consistent with the present invention; 

token is used to establish a shared secret between the local FIG. 9b illustrates a method for establishing a shared 

device and the remote device. secret between a smarl cafd afid a deyice an(J shadng 

Additional desires, features and advantages of the inven- 25 the secret with a local device; and 
tion are set forth in the following description, apparent from FIG. 9c illustrates a method for establishing a shared 
tiic description, or may be learned by practicing the inven- S6CKt betw66n a smart carf and a remot6 devic£ md ^ ng 

the smart card for transactions between the remote device 

Both the foregoing general description and the following anc j a j oca i device, 

detailed description are exemplary and explanatory and are 30 

intended to provide further explanation of the invention as DETAILED DESCRIPTION 

claimed. Reference will now be made in detail to the construction 

BRIEF DESCRIPTION OF THE DRAWINGS anc * °P erat i° n °f preferred embodiments consistent with the 

35 present invention that are illustrated in the accompanying 

The accompanying drawings, which are incorporated in drawings. In those drawings, like elements and operations 

and constitute a part of the specification, illustrate presently are designated with the same reference numbers, 

preferred embodiments of the invention and, together with Methods and systems consistent with the present inven- 

the preceding general description and the following detailed ti on est ablish a shared secret between parties communicat- 

description, explain the principles of the invention. ^ ing over a nct work to provide adequate mutual 

In the drawings: authentication, data encryption, and integrity protection. 

FIG. 1 illustrates a system for establishing a shared secret This is accomplished in a variety of ways as explained in . 

using an authentication token consistent with the present detail below. In one embodiment, for example, a shared 

invention; secret can be established using an authentication token ihat 

FIG. 2 illustrates a method for establishing a shared secret 45 generates a character string and is approximately time- 
using an authentication token consistent with the present synchronized with a remote device (e.g., server). The char- 
invention; acter string, for example, is a password based on the time of 

i mi * * *t_ j c * t_i • u- « j day encrypted with a secret code or a random number. The 

FIG. 3a illustrates a method for establishing a shared J * t ■ • • . j . i i j ■ / 

4 t. • j 4i_ *■ *• * ■ ■ character string is communicated to a local device (e.g., 

secret using a time-synchronized authentication token and a j * »• \ l L j-^j- j. - J 

uup*' • * « '.l. .t. <■ so workstation) where it can be modified using a predetermined 

hash function consistent with the present invention; n <• * j w ' j l * . • \ 

/ function to produce a result (i.e., a second character string). 

FIG. 36 illustrates a method for establishing a shared ^ result is ^ to the remotc device Qnce rcccived , tnc 

secret using a time-synchronized authentication token, a rcmotc dcvice comparcs mc rcsuIt with a finitc number of 

hash function and a limited number of character string bits possibk matching character string values relating to the 

consistent with the present invention; s$ initial characlcr string gcnC rated by the authentication token. 

FIG. 4a illustrates a method for establishing a shared The remote device and the user's local device can then share 

secret using a time-synchronized authentication token, a the matching value or a function of the matching value as a 

hash function and a PIN consistent with the present inven- seC ret to encrypt and enhance the integrity of information 

tlon i transferred therebetween, and/or perform mutual authenti- 

F1G. 4b illustrates a method for establishing a shared so cation. Alternatively, the remote and local devices may use 

secret using a time-synchronized authentication token, a their shared secret to establish a larger (and thus more 

hash function, a PIN, and a limited number of character secure) secret, which may be used to encrypt data, enhance 

string bits consistent with the present invention; the integrity of information transferred therebetween, and/or 

FIG. Sa illustrates a method for establishing a shared perform mutual authentication, 

secret using a time-synchronized authentication token and a 65 FIG. 1 illustrates a system 100 for establishing a shared 

shared secret key exchange protocol consistent with the secret using an authentication token consistent with the 

present invention; present invention. System 100 includes a workstation 120, 
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servers 130, 140, and 150, a network 160, and an authenti- cation token (step 200). The authentication token can be a 

cation token 170. One skilled in the art will appreciate that time- synchronized token, challenge response token, or any 

system 100 may include an unlimited amount of token configured to implement the authentication techniques 

workstations, servers, and other network components. described herein. The authentication token is then utilized to 

Workstation 120 is a computer capable of sending data to 5 establish a shared secret (step .220). Autlientication tech- 

and receiving data from network 160. Workstation 120 m ^ es for f | ab ^ n ^ shared secret are descnbed below 

to j ■ */ * * j ■ * with respect to FIGS. 3-8. 

includes a processor, memory, and input/output devices to \ .„ 4 A it _ , - . 

facilitate human interaction (not shown). Workstation 120 FI °' * a m " strates a . metho ^ f°r " abHshmg a shared 

i * r i *• *u *u *• *■ * u secret using a time -synchronized authentication token and a 

mcludes software for implementing the authentication tech- , , - J . 4 , , 4 , 

j j . . , t . Ct in hash function consistent with the present invention, 
niques described herein, such as encryption software. 10 ™ • ... „ 4 . . . , 
fc - , . -* A . , j , , / . . v Iraditionally, a user enters a character string into a work- 
Moreover, workstation 120 includes a modem (not shown) . , . . . ,\ 4 . * . A . , . 

4 . . j * i j c / station which transmits the character string to a server in the 

or other communications device to transfer data over net- , T , 4 t . . , t . 4 , , & 

i /-^ i mi j • «u * mi . t ,i , , clear. Implementations consistent with the present invention 

work 160. One skilled in the art will appreciate that work- , J . A . . . iL 1rkiL 

. - rr . . . . ■ do not send the character string in the clear. Rather, these 

station 120 may have any configuration consistent with the , . , ** . . ,. , , 

. j. t i j * • r i i**- i« implementations use the character string displayed on the 

embodiments descnbed herein. For example, workstation 15 5 *• . i * . L j * « ^_ 

^ A , - i • . i * authentication token to generate a shared secret between 

120 may rely on software stored in an external memory to . 4 . , L1 . . r 

. . .u j •« » i . . . . . communicating parties to provide a reasonable level of 

implement the described authentication techniques. *t. j 

r n authentication and a secure session. 

Servers 130,140 and 150 are included in FIG. 1 to ^ a character stri is generated on a time . 

illustrate the ability of workstation 120 to communicate with synchronized token 170 (step 300). Preferably, the character 

a plurality of network devices for authentication purposes stri ^ me time of d in minutes encrypted ^ a 

Each server is a computer capable of sending data to and ^ knQ wn Qm tQ tQe ^ and ^ servef Tfae charactef 

receiving data from network 160. Each server can be con- ^ fe men communicated t0 workstation 120 (step 310). 

figured for different applications and controlled by different Fof e fe the user can read ^ chafacter ^ and 

entities. For example, a bank may operate server 130 to manuallv enter it into the workstation, or, if connected, the 

allow remote access to customer financial data and a service- workstation can read the character stri automatically from 

oriented company may operate server 140 to permit remote the authentication token> Upon receivmg the character 

access to customer account information. In addition, a strf ^ wlkstatioil executes a commercially available 

manufacturing company may operate server 150 to facilitate hash m t0 te a hash of the character stri ( . 

customer access to order status information Each of these h(character strin g)) ( ste p 320). A hash is a cryptographic 

servers can store and control access to privileged informa- Qn fwakjQ ^ takes an ^ hiUaiy _ siztd input and 

tion. To this end, one or more authentication techniques as ields a fixed . sized out t ^ workstati on then sends 

descnbed herein ^are used to ensure that only intended parties h(character string) to server 130 ( ste p 330). 

receive the privileged information. r « c , , , , , . . t . , 

r & lo allow for clock skew and delays in typing and 

Network 160 is a communication medium, such as the 35 transmission, the server will accept any one of several 

Internet, that routes information between devices connected character strings, based on character strings the token might 

thereto. Although FIG. 1 shows computers connected to Qave displayed in the last seven minutes or the next three 

network 160, other components with communication capa- m i nut es (or other suitable values for the number of minutes), 

bilities may be connected to network 160 as well. For Because the number of acceptable character strings is small, 

simplicity, network 160 is often referred to herein as the ^ it ^ easy for tne to compute the hash of each 

Internet to illustrate how authentication tokens are used to acceptable character string and disambiguate a matching 

authenticate users of the Internet. Nevertheless, authentica- bash f rom me com p U ted hashes by comparing each hash to 

tion techniques consistent with the present invention may be the hash received, h(character string) (steps 340 and 350). If 

used on other WANs as well as local area networks (LANs), a match ^ not found? the authen ti ca tion attempt fails (step 

network protocols, and other communication media. 4$ 360) If a match fa found? the and wor kstation use a 

Authentication token 170 may include input (e.g., keypad, function of the character string (e.g., a hash of the character 
light pen, etc.) and output capabilities (e.g., LCD display, string, the character string itself, or other variations) as a 
speaker, etc.). The input capabilities allow information, such shared secret (step 370). That is, the server and workstation 
as character strings, to be communicated to authentication use a function of the matched character string to encrypt 
token 170. The output capabilities allow information to be 50 messages sent therebetween over network 160. This tech- 
communicated to a user or another device. Authentication nique is effective provided that the matched character string 
token may be time-synchronized with a remote device (i.e., has enough bits to protect against eavesdroppers. In most 
time-synchronized token), configured to process character types of tokens, the character strings generated are too short 
strings entered on its keypad to produce a response (i.e., (such as only 2 32 possible values). However, if the character 
challenge-response token), or designed to store information ss string is too short, an eavesdropper that captures h(character 
accessible only through an appropriate reader device (i.e., string) can determine the character string through an exhaus- 
smart card). To facilitate these operations, authentication tive search. 

token 170 preferably includes a processor and a memory F IG. 3b illustrates an implementation consistent with the 

(not shown). In addition, authentication token 170 may be present invention similar to that illustrated in FIG. 3a. This 

configured to require an activation code (e.g., PIN or 60 implementation includes steps 300-320 of FIG. 3a. 

biometric) for operation. Although authentication token 170 Nevertheless, instead of sending a complete hash of the 

may or may not be physically connected to workstation 120, character string to the server, as shown in step 330 of FIG. 

it is included in system 100 to implement authentication t ne implementation of FIG. 3b sends only a few bits of 

techniques described in detail below. the hashed the character string to the server (e.g., 12 bits of 

FIG. 2 illustrates a method for establishing a shared secret 65 a 64-bit hash of the character string) (step 335). The purpose 

using an authentication token consistent with the present of sending a hash of the character string to the server is for 

invention. The method begins with providing an authenti- server 130 to determine the correct character string from the 
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ten or so acceptable character strings (i.e., assuming the strings, will yield a different hash. The server then sends the 

clock skew is such that only ten character strings are needed constant to the workstation and requests the resulting hash, 

to determine the character string). Since server 130 needs The workstation then applies a function to hash the constant 

only to distinguish between a small number of character with the character string (i.e., (character string/constant)) 

strings, a few bits of the hashed character string will, with 5 and sends the combined hash character string to the server 

high probability, allow server 130 to compute a hash char- to match with one of the predetermined character strings, 

acter string that will not collide with any of the remaining From the matching character string, the server can compute 

nine character strings. the original character string and use it as a shared secret with 

The purpose of sending only a few bits of the hashed tne workstation. In using the foregoing authentication 

character string rather than a complete message digest is to 10 techniques, a user should be sure that the combined infor- 

foil an eavesdropper's efforts to narrow down the character mation (i.e., hash of character string and constant) does not 

string from the number of possibilities the eavesdropper provide an eavesdropper with enough information to deter- 

must search (i.e., 2 64 ). For example, if workstation 120 mine the character string. 

sends an eight-bit hash, approximately 2 56 character strings Another implementation of determining matching accept- 

will match that hash, and the eavesdropper has to search 2 S6 35 able values (i.e., disambiguating) is for the server to send a 

values to determine the correct character string. value to the workstation (e.g., after receiving a few bits of 

If the workstation sends an eight-bit hash character string a hash of a character string concatenated with a PIN). Using 

and the original character string has 64 bits of randomness, a function known to the server, the workstation generates an 

the probability that two or more of the ten character strings output value that represents a function of the original value 

will match the hash of the character string entered by the 20 ( sent from tne server) and the character string (from the 

user is 1 — (2S5/256) 9 or approximately 4%. If it is unac- authentication token) concatenated with a PIN. The resulting 

ceptable for approximately one in 40 authentication attempts output value is sent to the server and used to determine a 

to fail (because one of the nine other character strings hashes sin g le matching acceptable value. 

to the same character string as the original character string Once a shared secret has been established, the server and 

and the server guesses the wrong one), then the workstation 25 the workstation can easily perform mutual authentication, if 

can send a 16-bit hash, which still leaves the eavesdropper desired, with any of a number of well-known techniques for 

with I 48 values to search. performing mutual authentication based on a shared secret. 

After receiving only a few bits of the hash of the character These techniques are described in Network Security, page 
string, the server computes a hash of each of a plurality of 3Q 223. For instance, the server can implement a method to 
acceptable character string values and compares the com- prove that the workstation has the shared secret. This 
puted hash to the received bits (step 345). Based on the method begins with communicating a second character 
comparison, the server determines whether the received bits string from the server to the workstation, which implements 
match an acceptable character string value (step 355). If a function using the shared secret and/or the second char- 
there are no matches between the computed hash and 5 acter strin g ( SUCD as a nasn of the secret and the second 
received bits, the authentication attempt fails (step 360). If character string) to produce an output. The workstation then 
a match is found, the server determines whether the received sends the output to the server which compares the output to 
bits match more than one acceptable value (step 365). If the expected value to prove that the local device has the 
there is only one match, the server and workstation use a shared secret. This process can easily be reversed to allow 
function of the character string (e.g., a hash of the character the workstation to authenticate the server, 
string, the character string itself, or other variations) as a It is desirable that the server prove knowledge of the 
shared secret (step 370). If more than one match is found, the character string (or a small set of acceptable character 
server sends instructions to the workstation to disambiguate strings) before the workstation reveals information used to 
the hash of the character string (step 375). In this instance, determine the character string. Otherwise, a man in the 
a single matching acceptable value is determined while 45 middle or imposter server can play along in the protocol and 
communicating as little information as possible, a technique then use an exhaustive search to find the correct value and 
that is described in detail below. continue the session. This recommendation applies to each 

Failed authentication attempts can be avoided by having embodiment consistent with the present invention, 

the server notice that more than one of its predetermined FIG. 4a illustrates a method for establishing a shared 

character strings match the received hash, and request addi- 50 secret using a time-synchronized authentication token, a 

tional bits in the hash. Since the server knows all of the hash function and a PIN consistent with the present inven- 

possible matching character strings, it can request specific tion. This method avoids the problem of exhaustive search 

bits in the hash that it knows will differentiate the collided when the character strings generated by the token are too 

character strings (i.e., by sending an instruction to the short. 

workstation for the necessary bits). Another option is for the ss First, a character string is generated on a time- 
server to request the "next k bits," Requesting specific bits synchronized token 170 (step 400), The character string is 
allows the server to receive the fewest possible bits needed then communicated to workstation 120 along with a PIN 
to determine the original character string held by the work- ( step 410). For example, the user can read the character 
station. string and manually enter it into the workstation with a PIN, 
An additional alternative to the foregoing techniques is 60 or, if connected, the workstation can read the character string 
for the workstation not to send any bits of the hashed automatically from the authentication token after the user 
character string to the server initially, but rather have the has entered a PIN into the workstation. Upon receiving the 
server check the ten predetermined character strings and character string, the workstation executes a commercially 
request the minimum number of bits that will differentiate available hash program to generate a hash of the character 
those ten character strings. This technique can be further 65 string and the PIN (i.e., h(character string/PIN)) (step 420). 
modified such that the server computes a constant that, when The workstation then sends h(character string/PIN) to server 
hashed with each of the collided predetermined character 130 (step 430). Server 130 then computes h(character string/ 
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PIN) for each of a plurality of acceptable character strings 
using the PIN which is already known to the server and 
compares the acceptable character strings with h(character 
string/PIN) received from workstation 120 (step 440 and 
450). If a match is not found, the authentication attempt fails 
(step 460). If a match is found, the server and workstation 
use a function of the character string and the PIN (e.g., a 
hash of the character string concatenated with a PIN con- 
catenated with a constant) as a shared secret (step 470). 

FIG. 4b illustrates an implementation consistent with the 
present invention similar to that described above with ref- 
erence to FIG. 4a. This implementation shares steps 
400-420 of FIG. 4a, however, differs thereafter by sending 
only a limited number of bits of h(character string/PIN) to 
the server (step 435). After receiving only a few bits of 
h(character string/PIN), the server computes a hash of each 
of a plurality of acceptable character string values concat- 
enated with the PIN and compares the computed hash to the 
received bits (step 445). Based on the comparison, the server 
determines whether the received bits match an acceptable 
character string value (step 455). If there are no matches 
between the computed hash and received bits, the authen- 
tication attempt fails (step 460). If a match is found, the 
server determines whether the received bits match more than 
one acceptable value (step 465). If there is only one match, 
the server and workstation use a function of the character 
string (e.g., a hash of the character string concatenated with 
a PIN concatenated with a constant) as a shared secret (step 
470). If more than one match is found, the server sends 
instructions to the workstation to disambiguate the hash of 
the character string concatenated with a PIN (step 475). A 
single matching acceptable value is determined by using just 
enough bits of the hash of the character string. This can be 
accomplished by using one or more of the techniques 
described above with respect to FIG. 3b. 

In the aforementioned embodiment, the shared secret 
between the workstation and the server is a different function 
than h(character string/PIN). For instance, the hash character 
string sent from the workstation to the server might be 
SHA(character string/PIN) and the shared secret might be 
SHA(character string/PIN/constant) with the constant being 
previously known to the workstation and server. (SHA 
stands for "secure hash algorithm" which is a message digest 
function proposed by the National Institute of Standards and 
Technology (NIST)). This authentication technique works 
effectively with all time-synchronized tokens, provided that 
the PIN and the character string together include enough bits 
(e.g., 64-bits or more) to thwart an exhaustive search from 
an eavesdropper. 

FIGS. 5a-Sc illustrate a method for establishing a shared 
secret using a time-synchronized authentication token and a 
shared secret key exchange protocol consistent with the 
present invention. In this implementation, the secret (e.g., 
character string) shared between the workstation and server 
can be disambiguated either before implementing a shared 
secret key exchange protocol, while implementing a shared 
secret key exchange protocol, or after implementing a shared 
secret key exchange protocol. 

FIG. Sa illustrates a method of disambiguating a shared 
secret before implementing a shared secret key exchange 
protocol. This method begins with displaying a character 
string on a time-synchronized token 170 (step 500). The user 
then enters the character string into workstation 120 (step 
510). The workstation and server use the character string to 
establish a first shared secret, as described in any of the 
foregoing embodiments (step 520). Subsequently, the first 
shared secret can be used to establish a stronger shared 
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secret (e.g., a shared secret having more bits) using a shared 
secret key exchange protocol, such as the Bellovin-Merritt 
shared secret key exchange protocol (step 530). Once the 
stronger shared secret has been established, it may be used 

5 to encrypt traffic or perform other operations (step 540). 
FIG. Sb illustrates a method of disambiguating a shared 
secret while implementing a shared secret key exchange 
protocol. This method is similar to that illustrated in FIG. Sa, 
except that steps 520 and 530 are combined in FIG. Sb (step 

30 527). Several techniques allow a first shared secret to be 
disambiguated while implementing a shared secret key 
exchange protocol. One such technique is to use the 
Bellovin-Merritt shared secret key exchange protocol and 
have workstation 120 concatenate a constant into the first 

15 encrypted message of the shared secret key exchange pro- 
tocol and have server 130 check that the decrypted message 
includes the constant. Another is to have workstation 120 
concatenate some or all of the hash of the character string 
from the authentication token into the message before 

20 encryption and have server 130 check that the decrypted 
message includes the proper hash bits. A further technique is 
to have workstation 120 send some or all of the bits of the 
hash of the character string unencrypted along with the 
encrypted message. 

25 Alternatively, as illustrated in FIG. 5c , the shared secret 
key exchange protocol may be implemented using the 
character string from the authentication token (step 525) as 
a first shared secret without first disambiguating it. 
Subsequently, the character string can be disambiguated 

30 (step 535), thus determining the stronger shared secret 
established by the shared secret key exchange protocol (step 
540). 

For instance, a modified Bellovin-Merritt shared secret 

35 key exchange protocol may be implemented such that the 
server receives a first message encrypted with the character 
string from the workstation, chooses its part of the key, 
computes several values for the complete key based on the 
several acceptable values for the character string, and sends 

^ hashes of the complete keys along with its part of the key 
(unencrypted) to the workstation. The workstation can then 
determine the complete key and compare its hash to those 
received from the server. If there is a match, the server 
determined the character string (within a small set). At this 

4S point, the workstation may prove that it has the character 
string or second shared key via a challenge-response (where * 
the challenge may optionally have been sent with the 
previous message from the server). 

The foregoing techniques may be employed to establish 

50 the shared secret or avoid failed authentication attempts 
while minimizing the number of hash bits sent (e.g., such as 
having the server request more bits or send a constant that 
should be included in the hash to avoid collisions). The 
character string used as the basis for the shared secret key 

55 exchange protocol should be over 32 bits in length. If not, a 
PIN may be added to the character string before implement- 
ing the protocol to provide enhanced authentication. 

FIG. 6 illustrates a method for establishing a shared secret 
with a challenge-response authentication token consistent 

so with the present invention. The method begins with server 
130 sending a challenge (i.e., string of characters) to work- 
station 120 (step 600). Upon receipt, the user enters the 
challenge into a challenge-response authentication token 
(step 610). The authentication token processes the entered 

65 challenge and generates a response (step 620). The gener- 
ated response is then communicated to workstation 120 (step 
630) where it is used as a shared secret between the 



01/26/2004, EAST Version: 1.4.1 



US 6,173,400 Bl 

11 12 

workstation and the server (step 640). This authentication FIG. 9b illustrates a method for establishing a shared 

technique provides a high level of authentication between secret between a smart card and a remote device and sharing 

the workstation and the server as long as the length of the the secret with a local device. This method begins with 

response is sufficient (e.g., over 32-bits in length). If not, the providing a smart card (step 902). The smart card may be 

modification of this embodiment may be used to increase the 5 activated and use an internal or external clock as described 

level of authentication as described below with respect to above with respect to FIG. 9a. Moreover, the smart card may 

FIG. 7. include communication software and hardware to facilitate 

FIG, 7 illustrates a method for establishing a shared secret communication with a remote device. To this end, the smart 

with a challenge-response authentication token and a PIN card is capable of establishing a shared secret with the 

consistent with the present invention. This method begins 10 remote device using one or more of the foregoing techniques 

with server 130 sending a challenge to workstation 120 (step (i.e., the smart card can operate as an authentication token 

700). Upon receipt, the user enters the challenge into a and workstation to establish a shared secret with a remote 

challenge-response authentication token (step 710). The server) (step 922). For example, the smart card can generate 

authentication token processes the entered challenge and a fast character string and communicate it to a remote device 

generates a response (step 720). The user then enters the wner e it is matched with one of a plurality of acceptable 

generated response into workstation 120 along with a PIN values. A shared secret can also be established by commu- 

(step 730), Finally, workstation 120 and server 130 can use nicating a first character string from a remote device to the 

a function of the response and PIN as a shared secret (step smrt cafd and rocessin me first character strin on the 

740). This embodiment provides a high level of authentica- smart card tQ rate a second chafacter ^ ^ can be 

tion when the response and PIN are lone enough for a « . to . . ™ _* j tL 

session ke (e over 32 bits in len th) 20 u ^ a snarec * secret- The smart card can then commum- 

SC ^!? o mi * ^7 ° Ver ? n ^,. . . , cate the shared secret to the workstation for user 

FIG. 8 illustrates a method for establishing a shared secret *u *• a ♦ ~ *■ a • * •« * *• 

... . „ . < , • . i i L , authentication, data encryption, and integrity protection 

with a challenge-response authentication token and shared ( qa^ 

secret key exchange protocol consistent with the present A . " . . 

invention. Initially, server 130 sends a challenge to work- FIG - 9c illustrates a method for establishing a shared 

station 120 (step 800); Upon receipt, the user enters the 25 secret between a smart car ^ and a remote device and using 

challenge into a challenge-response authentication token tne smart caf d for transactions between the remote device 

(step 810), perhaps with a PIN. The authentication token and a local device. This method begins with providing a 

then processes the entered challenge and generates a smart card (step 904). The smart card may be activated and 

response (step 820). The user enters the response into use an internal or external clock as described above with 

workstation 120 (step 830) where it is used to conduct a 30 respect to FIG. 9a. Moreover, the smart card may include 

shared secret key exchange protocol (step 840). Both work- communication software and hardware to facilitate commu- 

station 120 and server 130 use the secret determined by the nications with a remote device. To this end, the smart card 

key exchange as a shared secret (step 850). Alternatively, a is capable of establishing a shared secret with the remote 

function of the response (e.g., a hash of the response with device using one or more of the foregoing techniques (step 

another PIN) can be used in the key exchange to further 35 924). This method differs from that described with reference 

enhance authentication between workstation 120 and server to FIG. 9b in that once a shared secret is established, the 

130. smart card does not communicate it to the workstation. That 

FIGS. 9a-9c illustrate methods for establishing a shared the smart card and shared secret are utilized in transac- 

secret using a smart card consistent with the present inven- tions between the remote device and the local device without 

tion. In particular, FIG. 9a illustrates a method for estab- 40 ever revealing the shared secret to the local device (step 

lishing a shared secret between a local device and a remote 944). 

device using a smart card consistent with the present inven- Embodiments consistent with the present invention pro- 

tion. The method begins with providing a smart card (step vide adequate authentication and enhance the integrity of 

900), The smart card may be activated using an activation information transferred between parties over a communica- 

code. The activation code can include a PIN, a biometric, or 45 tion medium. The authentication techniques described 

other form of input. In addition, the smart card may have an herein allow a user to customize their level of authentication 

internal clock for processing data or operate using an based on the type of token used and the available software 

external clock (e.g., the workstation clock). Once activated, on the workstation and server. For example, both the work- 

the card communicates data (e.g., a character string) to a station and server may only have hashing and encryption 

local device, such as a workstation (step 920). The work- 50 software. However, with only these two types of software 

station may be configured to receive the data through a card and an authentication token, the workstation and server are 

reader or directly using an internal receiver and appropriate capable of providing sophisticated levels of authentication 

software. using the foregoing techniques. 

Upon receiving the data, the workstation can utilize it to While there has been illustrated and described preferred 
establish a shared secret with a remote device, such as a ss embodiments and methods of the present invention, those 
server, using any one of the techniques described above with skilled in the art will understand that various changes and 
regard to the time-synchronized and challenge-response modifications may be made, and equivalents may be sub- 
authentication tokens (step 940). For example, the worksta- stituted for elements thereof, without departing from the true 
tion can generate a first character string and communicate it scope of the invention. 

to a remote device where it is matched with one of a plurality 60 In addition, many modifications may be made to adapt a 

of acceptable values. A shared secret can also be established particular element, technique or implementation to the 

by communicating a first character string from a remote teachings of the present invention without departing from 

device to the workstation and processing the first character the central scope of the invention. Therefore, this invention 

string on the workstation to generate a second character should not be limited to the particular embodiments and 

string that can be used as a shared secret. The shared secret 65 methods disclosed herein, but should include all embodi- 

can then be used for user authentication, data encryption, ments falling within the scope of the appended claims, 

and integrity protection. What is claimed is: 
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1. A method for establishing a shared secret among a 
plurality of devices, comprising the steps of: 

providing an authentication token; 

generating a first character string on the authentication 
token; 5 

communicating the first character string to a local device; 

creating a second character string from the first character 
string on the local device; 

sending the second character string to a remote device; 10 

disambiguating the second character string from a plural- 
ity of predicted character string values; and 

utilizing at least one of the plurality of predicted character 
string values to establish a shared secret between the 
local device and the remote device. 15 

2. The method of claim 1 further comprising the step of 
implementing a shared secret key exchange protocol using 
the first character string to establish a shared secret with the 
remote device. 

3. The method of claim 2 wherein the implementing step 20 
includes the steps of: 

disambiguating the first character string from a plurality 

of predicted character string values; and 
implementing the shared secret key exchange protocol 25 

after the first character string is disambiguated. 

4. The method of claim 2 wherein the implementing step 
includes the steps of: 

disambiguating the first character string from a plurality 
of predicted character string values; and 30 

implementing the shared secret key exchange protocol 
while the first character string is disambiguated. 

5. The method of claim 2 wherein the implementing step 
includes the steps of: 

implementing the shared secret key exchange protocol; 35 
and 

disambiguating the first character string from a plurality 
of predicted character string values after the shared 
secret key exchange protocol is implemented, 

6. The method of claim 2 wherein the implementing step 40 
includes the step of implementing a shared secret key 
exchange protocol using the first character string and a 
personal identification number to establish a shared secret 
with the remote device. 

7. The method of claim 1 wherein the creating step 45 
includes the step of implementing a function of the first 
character string to generate the second character string. 

8. The method of claim I wherein the providing step 
includes the step of providing a smart card. 

9. The method of claim 1 further comprising the steps of 50 
proving to the remote device that the local device has the 
shared secret. 

10. The method of claim 9 wherein the proving step 
includes the steps of: 

communicating a third character string from the remote 

device to the local device; 
implementing a function on the local device using at least 

one of the shared secret and the third character string to 

produce an output; 60 
sending the output to the remote device; and 
comparing the output with a predicted character string 

value to prove that the local device has the shared 

secret. 

11. The method of claim 1 further comprising the step of 65 
proving to the local device that the remote device has the 
shared secret. 
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12. The method of claim 11 wherein the proving step 
includes the steps of: 

communicating a third character string from the local 

device to the remote device; 
implementing a function on the remote device using at 

least one of the shared secret and the third character 

string to produce an output; 
sending the output to the local device; and 
comparing the output with a predicted character string 

value to prove that the remote device has the shared 

secret. 

13. The method of claim 1 wherein the creating step 
includes the step of creating the second character string 
using the first character string and a personal identification 
number. 

14. The method of claim 1 wherein the creating step 
includes the step of implementing a hash function to create 
the second character string from the first character string. 

15. The method of claim 1 wherein the sending step 
includes the step of sending only a portion of the second 
character string to the remote device. 

16. The method of claim 1 further comprising the step of 
communicating an instruction from the remote device to the 
local device for information required to disambiguate the 
second character string from the at least one of a plurality of 
predicted character string values. 

17. The method of claim 16 further comprising the step of 
generating an output value on the workstation, in response 
to the instruction, used to disambiguate the second character 
string from the at least one of a plurality of predicted 
character string values. 

18. The method of claim 1 further comprising the step of 
activating the authentication token with an activation code. 

19. The method of claim 1 wherein the providing step 
includes the step of providing an authentication token that is 
approximately time-synchronized with at least one of the 
plurality of devices. 

20. A method for establishing a shared secret among a 
plurality of devices, comprising the steps of: 

providing an authentication token; 

communicating a first character string from a remote 
device to the authentication token; 

processing the first character string using the authentica- 
tion token to generate a second character string; 

sending the second character string to a local device; and 

utilizing the second character string to establish a shared 
secret with a remote device. 

21. The method of claim 20 further comprising the step of 
activating the authentication token with an activation code. 

22. The method of claim 20 wherein the sending step 
includes the step of communicating a personal identification 
number along with the second character string to the local 
device. 

23. The method of claim 20 wherein the utilizing step 
includes the step of implementing a shared secret key 
exchange protocol with the second character string to estab- 
lish a shared secret. 

24. The method of claim 20 wherein the utilizing step 
includes the step of implementing a shared secret key 
exchange protocol with the second character string and a 
personal identification number to establish a shared secret. 

25. A method for establishing a shared secret among a 
plurality of devices, comprising the steps of: 

providing an authentication token; and 
utilizing the authentication token to establish a shared 
secret among the plurality of devices. 
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26. The method of claim 25 wherein the providing step 43. The system of claim 37 wherein the sending means 
includes the step of providing a smart card. include means for sending less than a total number of bits of 

27. A system for establishing a shared secret among a the second character string to the remote device, 
plurality of devices, comprising: 44. The system of claim 37 further comprising means for 

an authentication token; 5 transferring an instruction from the remote device to the 

a local device* and ^ oca ^ device f° r information required to disambiguate the 

, , / second character string from the at least one of a plurality of 

a remote device, t , . t °. , r J 

' predicted character stnng values. 

wherein the authentication token is used to establish a 45. The system of claim 44 wherein the transferring 

shared secret between the local device and the remote 10 means include means for providing a constant with the 

device, instruction from the remote device to the local device that is 

28. The system of claim 27 wherein the authentication processed with the second character string using a hash 
token is approximately time -synchronized with the remote algorithm. 

device. 46. The system of claim 37 wherein the generating means 

29. The system of claim 27 wherein the authentication 15 includes means for activating the authentication token with 
token includes a processor. an activation code, 

30. The system of claim 27 wherein the authentication 47. a system for establishing a shared secret among a 
token is configured to receive an input. plurality of devices, comprising: 

31. The system of claim 27 wherein the authentication a j oca i device* 
token is configured to produce an output. 2 o 

32. The system of claim 27 wherein the authentication a rcmote device; 
token includes a display. an authentication token; 

33. The system of claim 32 wherein the authentication means for determining a first character string using the 
token includes means for generating a character string remote device; 

viewable on the display. ^ means f or sending the first character string to the authen- 

34. The system of claim 27 wherein the local device is a tication token; 

workstation. means for processing the first character string to produce 

35. The system of claim 27 wherein the remote device is a sccond charactcr striog; and 

3 S f T^r^L 4 r 1 • 11 L • iL means for communicating the second character string into 

36. Ine system 01 claim 27 wherein the authentication -in *i_ 1 1 j • u * * j • j 

A * » j ^ the local device such that the remote device and the 

token is a smart card. 1 1 j * u .u j u ♦ * • 

. , r x t . . . , local device share the second character string as a 

37. A system tor establishing a shared secret among a secret 

plurality of devices, comprising. ^ . system of claim 47 wherein the authentication 

a local device; token is a challenge-response token, 

a remote device; 35 49 j^e system of claim 47 further comprising means for 

an authentication token; entering an activation code into the authentication token, 

means for generating a first character string on the authen- 50. The system of claim 47 further comprising means for 

tication token; entering a personal identification number into the local 

means for communicating the first character string to the device. 

local device- 51. The system of claim 47 further comprising means for 

means for manipulating the finst character string using a ^P^nting a shared secret key exchange protocol using 

predetermined function to generate a second character ^ fcond character stnng. 

t ■ 52. A method for establishing a shared secret among a 

' , , . , plurality of devices, comprising the steps of: 

means for sending the second character stnng to the 45 / 

remote device; and providing a smart card; 

means for matching the second character string with at communicating data from the smart card to a local device; 

least one of a plurality of predicted character string m 

values to establish a shared secret between the local utilizing the data to establish a shared secret between the 

device and the remote device. so local device and a remote device. 

38. The system of claim 37 wherein the authentication 53 * ^ method of claim 52 further comprising the step of 
token is an approximate time-synchronized token. activating the smart card with an activation code. 

39. The system of claim 37 wherein the manipulating . 54 ^ method of claim 53 wherein the activation code 
means include means for executing a hash function using the fc a personal identification number. 

first character string as an input to produce the second 55 , 55 * ^ method of claim 53 wherein the activation code 

character string. » a biometric. 

40. The system of claim 37 wherein the manipulating 56 * ^ melhod of claim 52 wherein the providing step 
means include means for executing a hash function using the includes the step of providing a smart card with an internal 
first character string and a personal identification number as clock. 

an input to produce the second character string. 60 57 * ^ method of claim 52 wherein the providing step 

41. The system of claim 37 further comprising means for includes the step of providing a smart card that utilizes an 
implementing a shared secret key exchange protocol using external clock. 

the first character string to produce a shared secret. 58 - A method for establishing a shared secret among a 

42. The system of claim 41 wherein the implementing plurality of devices, comprising the steps of: 
means includes means for implementing a shared secret key 65 providing a smart card; 

exchange protocol using the first character string and a establishing a shared secret between the smart card and a 

personal identification number to produce a shared secret. remote device; and 
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communicating the shared secret from the smart card to a 
local device to establish the shared secret between the 
local device, smart card, and remote device. 

59. The method of claim 58 wherein the establishing step 
includes the steps of: 5 

generating a first character string on the smart card; 
communicating the first character string to the remote 
device; and 

utilizing the first character string to establish a shared 
secret with the remote device. 

60. The method of claim 58 wherein the establishing step 
includes the steps of: 

communicating a first character string from the remote 
device to the smart card; and 15 

processing the first character string on the smart card to 
generate a second character string used to establish a 
shared secret. 

61. The method of claim 58 further comprising the step of 
activating the smart card with an activation code. 20 

62. The method of claim 61 wherein the activation code 
is a personal identification number. 

63. The method of claim 61 wherein the activation code 
is a biometric. 

64. The method of claim 58 wherein the providing step 25 
includes the step of providing a smart card with an internal 
clock. 

65. The method of claim 58 wherein the providing step 
includes the step of providing a smart card that utilizes an 
external clock. 30 

66. A method for establishing a shared secret among a 
plurality of devices, comprising the steps of: 

providing a smart card; 
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establishing a shared secret between the smart card and a 
remote device; and 

utilizing the smart card and the shared secret in transac- 
tions between the remote device and a local device. 

67. The method of claim 66 wherein the establishing step 
includes the steps of: 

generating a first character string on the smart card; 
communicating the first character string to the remote 
device; and 

utilizing the first character string to establish a shared 
secret with the remote device. 

68. The method of claim 66 wherein the establishing step 
includes the steps of: 

communicating a first character string from the remote 

device to the smart card; and 
processing the first character string on the smart card to 

generate a second character string used to establish a 

shared secret. 

69. The method of claim 66 further comprising the step of 
activating the smart card with an activation code. 

70. The method of claim 69 wherein the activation code 
is a personal identification number, 

71. The method of claim 69 wherein the activation code 
is a biometric. 

72. The method of claim 66 wherein the providing step 
includes the step of providing a smart card with an internal 
clock. 

73. The method of claim 66 wherein the providing step 
includes the step of providing a smart card that utilizes an 
external clock. 

***** 
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